home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16019 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 21:36:36 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kcpgkINNcku@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <dewar.829012486@schonberg>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  12.  >Peter said
  13.  >
  14.  >">Something which works only on some systems is
  15.  >>not a portability problem *if there is no standard saying it works*.  Likewise
  16.  >>       i = ++i;
  17.  >>producing different results on different machines is not a "portability
  18.  >>problem"."
  19.  >
  20.  >This is a perfect case of Peter saying: Language X ensures that all
  21.  >portable programs are portable, therefore there are no portability
  22.  >problems. This is of course vacuously true for all languages!
  23.  
  24. I'm not sure that he means this vacuous truth. I think that Peter would say
  25. that a program is portable if it is strictly compliant to a standard. In the
  26. case of C that means it avoids invoking implementation-defined and unspecified
  27. behavior, and certainly undefined behavior.
  28.  
  29.  >By a "portability problem" most people mean that you take a program 
  30.  >written in language X, and try to move it to machine Y from machine Z,
  31.  >and it does not work any more.
  32.  
  33. Yes, according to your empirical/pragmatic conception of portabilitity.
  34.  
  35.  >Portability problems are most definitely caused by writing non-portable
  36.  >code. In fact in the absence of errors in the compiler of environment
  37.  >on machine Y or machine Z, this is the ONLY source of portability
  38.  >problems.
  39.  >
  40.  >However, it is definitely the case that languages vary in the ease with
  41.  >which people end up writing non-portable code deliberately or
  42.  >accidentally.
  43.  >
  44.  >For example, in C, we can't declare an integer variable without 
  45.  >introducing a potential portability dpeendence on the range. Careful
  46.  
  47. It's not that bad because there are those ``minimum maximums'' defined by the
  48. ANSI standard for <limits.h>. An int is at least -32767 to 32767, a long is
  49. at least -2^31+1 to 2^31-1, and an unsigned long at least 2^32-1. These ranges
  50. are guaranteed, and can be assumed by any portable program.
  51.  
  52.  
  53. From Peter Seebach's FAQ:
  54.  
  55. Herewith, some infrequently-asked questions and their answers:
  56.  
  57. Section 1. Declarations and Initializations
  58.  
  59. 1.1:    How do you decide which integer type to use?
  60.  
  61. A:    Use ``short'' when you need to avoid values over 32,767, ``int'' when
  62.     you want to store integers, ``long'' for long numbers (more than 6
  63.     digits), and ``float'' for numbers over 4 billion.
  64.  
  65. 1.2:    What should the 64-bit type on new, 64-bit machines be?
  66.  
  67. A:    int.
  68.  
  69. 1.3:    If I write the code
  70.  
  71.         int i, j;
  72.     
  73.     can I assume that (&i + 1) == &j?
  74.  
  75. A:    Only sometimes.  It's not portable, because in EBCDIC, i and j are
  76.     not adjacent.
  77.  
  78.  
  79. Pretty easy, if you ask me!
  80. -- 
  81.  
  82.